Notes synthétiques du meeting IRC #wordpress-dev du 7 août 2013.
C’est le meeting initial des développeurs de WordPress 3.7.
https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-08-07&sort=asc
Quelques 211 personnes suivent le tchat. Il est 22h en europe centrale, 13h à San Francisco.
Après quelques plaisanteries, Nacin ouvre les délibérations. Il recommande la lecture de son article sur make/core, et les informations données par Matt durant le récent #wcsf (WordCamp San Francisco), concernant les cycles 3.7 et 3.8.
taupecat recommande aussi la présentation the Mark Jaquith au #wcsf – une bonne partie des concepts présentés pourraient intégrer WP 3.7.
Une Roadmap pour WordPress 3.7
Le développement de 3.7 sera un peu différent des cycles précédents. Nous allons tenter d’appliquer des méthodes de développement rapide (qui rapelleront à certains la version 3.0)
Nous allons travailler dans un délai plus court, avec des focus plus étroitement limités – certains se souviendront de la version 3.2, qui nous a pris quatre mois. Pour 3.7 nous nous donnons deux mois.
La date prévue est début octobre. Vraisemblablement après le WordCamp Europe, mais avant le milieu du mois, donc la semaine du 7 octobre.
Les délais seront serrés. Quelques semaines en “alpha”, puis quelques semaines en “beta”, puis deux semaines de Release Candidates. En tout et pour tout, nous avons six semaines de travail.
Les buts spécifiques sont restreints. Il y en a trois:
- Les packs de languages (Language Packs)
- Les mises à jour automatiques pour les version intermédiaires
- Quelques améliorations pour aider les gens à consolider leurs mots de passe
Tous ces points ont déjà des tickets, plugins, patches, etc. La mission de ces prochaines semaines sera de les intégrer dans le Core et vérifier que tout marche.
Language Packs
Concernant les Language Packs, plus de détails ici:
nacin: http://core.trac.wordpress.org/ticket/18200
Implement language packs for core, plugins, and themes.
Inspiration and code can hopefully be derived from the corresponding GSoC project.
This will require quite a bit of work in GlotPress, on api.wordpress.org, and in core. I will take point, but assistance will be needed. A number of decisions will need to be made. I will begin designing a document for what exactly needs to be done over the next week.
photomatt: Les “Language Packs” seront probablement le point qui aura le plus d’impact – ce sera fabuleux pour l’adoption internationale.
MarkJaquith: la gestion des traductions est un poids très lourd pour les auteurs de plugins. On se réjouit d’être soulagés de ce fardeau.
tw2113: MarkJaquith, est-ce que avec les Language Packs, nous n’aurons plus besoin d’utiliser poedit pour créer nos fichiers “pot”?
Nacin: bonne remarque! En fait, nous avons maintenant un outil pour créer les fichiers “pot”, ça s’appelle makepot.php, et c’est intégré au core – https://github.com/wp-mirrors/wp-i18n-tools
Concernant l’international (i18n) – s’il y a des gens intéressés à contribuer à GlotPress, un sympatique outil écrit par nikolayb et actuellement maintenu par markoheijnen, il y aurait quelques avancées nécessaires pour le support des Language Packs.
Mises à jour automatiques:
Nous allons implémenter une mise à jour automatique pour les versions mineures d’une même branche (ces versions étant des corrections de bugs ou patches de sécurité) p.ex. de 3.7 => 3.7.1.
Il existe déjà un plugin qui fait ça: http://wordpress.org/plugins/automatic-updater/
nofearinc: L’idée est d’intégrer ce plugin?
Nacin: Oui, à peu près. Nous verrons comment nous arrangerons les détails en terme de notifications, UI, etc. A définir.
Autres initiatives
En plus de ces trois points-focus, le cycle 3.7 comportera quelques initiatives:
Un projet, déjà entamé, est le “build process”, qui intègre des tests et outils. Kooperfield est responsable de ce chantier. Voir http://make.wordpress.org/core/2013/08/06/a-new-frontier-for-core-development/
developer.wordpress.org a été annoncé au #wcsf comme un portail d’information pour développeurs de thèmes et plugins.
Un nouveau standard de documentation intégrée au code (“inline documentation”) est en développement.
Une autre initiative: réduire le nombre de tickets ouverts dans Trac.
Nous en sommes à 3800, le nombre a augmenté considérablement depuis peu.
Durant ce cycle, nous allons faire un gros nettoyage dans Trac!
Durant #wcsf, on s’est laché sur Trac pendant une journée et demie, et avons fermé plus de 100 tickets.
J’aimerais voir les gens former des groupes d’intérêt, autour de leurs spécialités.
P.ex. il y a 44 tickets concernant les flux RSS. Il y a 16 tickets sur les questions de date/heure. Ou 134 tickets concernant les commentaires. Il faut défricher ceux qui ont besoin de rester ouverts, ceux qui doivent être fermés, ceux qui sont prêts à être commités.
Cette semaine, nous allons activer sur Trac une nouvelle arborescence des composantes (“components”).
Nous ajouterons aussi une nouvelle fonction à Trac, permettant de s’abonner à un “component” (plutôt qu’à un ticket).
Notre objectif sera de donner à des contributeurs (et groupes de contributeurs) des moyens pour faire avancer les tickets et composantes.
Il y a beaucoup de gens, par exemple, qui veulent travailler sur le JavaScript. Ou l’accessibilité. Ou les tests unitaires, et le processus de “build”. Ou le multisite, ou les Post Types.
Nous aimerions voire des groupes s’organiser organiquement autour de ces centres d’intérêts.
Les committeurs (personnes ayant capacité d’intégrer un patch au code) seront très actifs durant ce cycle, donc un simple commentaire suffira pour obtenir de l’attention.
coenjacobs: Il est temps d’aller déterrer de vieux trésors :)
nacin: BINGO. :-)